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Abstract. In this paper, we present some guidelines for implementing 
various financial instruments for the purposes of credit and payment, 
including protocols for commercial transactions, dispute resolution, and 
establishing credit reputation. We strive to employ only widely used, 
standardized cryptography and keep the proposed procedures as simple 
as possible on the conceptual level. Also, we want all the documents 
to resemble their paper-based counterparts as closely as possible and 
be readable by humans, while also facilitating automated processing by 
computers. The presented results are being actively implemented within 
the ePoint System framework. 

1 Introduction 

Electronic commerce is currently severely hampered by the lack of reliable finan- 
cial and legal services matching the speed and convenience of on-line transac- 
tions. When online contracts are made by filling out and submitting web forms 
(with no customer copy beyond an easily forgeable confirmation email) and pay- 
ment authorization is done by entering one's credit card details, all involved 
parties are highly vulnerable to fraud. In case of such fraud, especially in an 
international setting, legal proceedings are prohibitively slow and expensive and 
fraught with inconsistent rulings due to the lack of reliable evidence. 

The problems resulting from the lack of common jurisdiction, ill-equipped 
central authorities and impracticality of coercive enforcement of contracts are 
nothing new; international trade has always been beset by such problems [4,5]. 
The body of laws and customs for international trade, commonly known as Lex 
Mercatoria[3, 8], provides us with both inspiration and guidance for designing a 
set of on-line protocols for overcoming the above described difficulties in elec- 
tronic commerce. In this paper, we describe some core techniques and procedures 



concerning financial instruments used for payment and credit that rely as much 
as possible on the existing infrastructure. 

OpenPGP[l] is the IETF standard inspired by Phil Zimmerman's PGP pro- 
gram that, among other things, describes digitally signed documents and facil- 
ities for peer-to-peer certification of public keys. Over time, a distributed, de- 
centralized, massively redundant network of so-called Public Key Servers (PKS) 
has been established, based on Mark Horowitz's web- and email-based protocol 
(HKP[2]). At the time of writing, the peer-to-peer certification facility and the 
PKS network is used solely for establishing bindings between public keys and 
identities and the trustworthiness of participants in such matters, forming the 
so-called PGP Web of Trust. However, as shown in this paper, this infrastruc- 
ture can be leveraged for the purpose of the more general task of reputation 
tracking. In particular, for recording and disseminating arbitrator decisions and 
other information affecting credit reputation. 

Our goal is to design procedures that can be easily understood by the Internet- 
using public. In particular, we would like to avoid relying on "exotic cryptog- 
raphy" that is conceptually difficult to grasp. Instead, we rely on third parties 
that require only very limited trust (e.g. PKS servers, time stampers, etc.). Also, 
we often forfeit the ability to prevent fraud by making it infeasible; instead, we 
deter it by reactive security measures made possible by strong evidence in the 
spirit of Lex Mercatoria. 

2 Electronic Evidence 

Unfortunately, Lex Mercatoria is often not applicable directly to electronic com- 
merce, because many of its implicit assumptions break down on the Internet. 
Also, in many cases, contemporary telecommunications allow for short-cuts and 
considerable improvements in efficiency over customary practices. 

Traditionally, documentary evidence is the result of marking paper with ink. 
Once the paper is marked, it is very difficult to remove these marks as if they 
have never been there and it is often also difficult to make an exact duplicate 
of the unmarked document. With electronic documents, this is not the case; 
any change to a document can be reversed with minimal effort, precisely by the 
way of keeping an exact duplicate of the unmarked version, which is practically 
free. This problem alone renders large parts of Lex Mercatoria inapplicable to 
electronic transactions, at least directly. 

Instead, in the digital world, the irreversible operation is revealing informa- 
tion that was not previously known [11]. It is very costly to force someone to 
forget a piece of information and it is even more problematic to completely erase 
something from the public records. Conveniently, PKS infrastructure provides 
us with straightforward means to irreversibly publish pieces of information. 

The above implies that digital signatures cannot, in a legal sense, be always 
treated as digital equivalents of pen-and-paper signatures[9] or even seals [10] 
(with which they actually have more in common, as a seal can be stolen just 
like a private key). There is a qualitative difference between the two, limiting 



the usefulness of the metaphor. Instead, digital signatures should be treated as 
an integrity protection mechanism; evidence witnessed by the signer that the 
document has not been altered by unauthorized parties. 

3 Digital Representations of Debt and Credit Reputation 

3.1 General Negotiable Financial Instrument 

Traditionally, negotiable instrument is generally defined as a transferable, signed 
document that unconditionally promises to pay the bearer a sum of money at a 
future date or on demand. Negotiable instruments are commonly used in business 
transactions to finance the movement of goods and to secure and distribute loans. 
Examples include cheques, bills of exchange, and promissory notes. All of them 
have statutory requirements that define their main elements, and these should 
be strictly fulfilled. It is also important to emphasize that there is a number of 
similar financial instruments, such as letters of credit that are treated separately 
by law and custom, which, nevertheless, can be represented digitally in a very 
similar way [6, 7]. 

In addition to their paper-based equivalents, digital instruments must include 
a cryptographic challenge corresponding to a secret known to the bearer of the 
instrument . Endorsements must include a proof of knowledge of this secret (typ- 
ically, the secret itself) and a new challenge corresponding to a secret known to 
the new bearer. Technically, revealing such a secret invalidates the instrument; 
endorsements are, in fact, back-to-back instruments carrying the same promise. 
The exact legal interpretation will hopefully emerge from future precedents. 

It is possible to turn these instruments into smart contracts [12], that are 
automatically processed by suitable machinery. We believe that this approach 
has some very important benefits over expressing smart contracts in universal 
programming languages (even specialized ones, such as E [14]), such as limiting 
the possibility of obfuscation and being generally readable to non-programmers. 

3.2 General Reputation Record 

A rarely used feature of OpcnPGP called "notation data" embedded in signa- 
tures (only available since version 4) allows OpcnPGP users to make elaborate 
statements about themselves and one another. It can be used in combination 
with another rarely used (and only partially implemented) feature: signatures 
made directly on the public key of the subject (tag OxlF, see Section 5.2.1. of 
[1]), which make it impossible for the subjects to get rid of these statements 
without discarding their entire digital identity and reputation. 

Such statements can be disseminated (reliably and irreversibly) using the 
existing PKS infrastructure. All the techniques that have been developed (and 
already implemented) for judging the reliability of statements about the iden- 
tities corresponding to public keys can be directly applied to statements about 
their creditworthiness, with relevant information written into notation data. 



4 Arbitration 



In this section, we outline the arbitration protocol, with Alice being the claimant, 
Bob the respondent and Justin the arbitrator. 

First, Alice sends a claim against Bob to Justin, including evidence support- 
ing her claim and a digital invoice (payable by Bob) for the value claimed. After 
receiving it, Justin invoices Alice for the arbitration fee. This invoice refers to 
Alice's statement of claim by hash value. 

Once the fee is paid, Justin notifies Bob, presenting him with Alice's claim 
and the supporting evidence. This is done automatically, without human inter- 
vention. 

Bob, at this point, has four options: 

1. He can settle by paying Alice the claimed amount; this would be evidenced 
by a signed transaction record containing the same cryptographic challenge 
and value as Alice's statement of claim. 

2. He can contest Alice's claim. At this point, he should also present Justin 
with evidence proving Alice's claim wrongful. Justin acknowledges receiving 
Bob's documents in a signed receipt, referring to each document and Alice's 
statement of claim by hash value. 

3. Bob may also demur at Alice's claim. This means that Bob is not contesting 
any of the factual statements, but informs Justin that in his view they do 
not imply that Bob should pay anything to Alice. It is the formal way of 
saying "so what?". The demurrer is a document signed by Bob referring 
to Alice's statement of claim by hash value. Justin acknowledges receiving 
Bob's demurrer in a signed receipt with the corresponding hash value. 

4. Bob may do nothing within the time frame allotted for responding to Alice's 
claim. 

The consequence of the first choice is that the case is closed. Clearly, from 
Justin's point of view, this is the most desirable outcome, as he ends up pocketing 
the arbitration fee, without using human resources. 

In the second case, Justin proceeds with evaluating the available evidence. 
Depending on its nature, the process can be automated to some extent. In some 
cases it can be even fully automated. If Alice's claim does not stand up, both 
Alice and Bob get notified about the case being closed. If Justin finds Bob in the 
wrong, then Bob is invoiced for damages and arbitration. If he fails to pay this 
invoice on time, then Alice shall receive a demerit signature of Justin on Bob's 
key, which she is free to upload to the PKS network. 

In the third case, Justin decides on the demurrer assuming that the factual 
statements in Alice's claim are true. Otherwise, however, the demurrer is not 
an admission of those facts by Bob. If the demurrer is sustained, both parties 
receive a signed statement to this effect from Justin and the case is closed. If 
not, the case proceeds as if Bob decided to do nothing. The reason for using the 
largely obsolete demurrer is that its use results in possibly crucial evidence for 
other arbitration procedures connected to the one in question, such as appeals 
or disputes further up the endorsement chain of some negotiable instrument. 



The consequences of the fourth choice (doing nothing) also depend on the 
particular case. In general, Bob should not be encouraged to delay arbitration by 
doing nothing, but on the other hand Bob should be protected from harassment. 

5 Acknowledgements and Final Remarks 
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A server program processing various financial instruments is described in 
detail in Janis Schuller's thesis [13]. This piece of software will be the basis 
for the reference implementation of the protocols and data formats used for 
procedures described above. 

For a detailed discussion with examples, please see the full version of this pa- 
per available online at http: //www.epointsystem. org/~nagydani/f c2008 .pdf 
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